COMMENT ⊗   VALID 00006 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00002 00002	 8-Oct-80 11:35:19-PDT,763000000000001
C00005 00003	Mailed about noon, 21-October-80
C00047 00004	∂22-Oct-80  2038	RICK at RAND-AI 	Re: Comments about ROSIE/Tutorial/etc.
C00051 00005	∂22-Oct-80  2037	GORLIN at RAND-AI (Dan Gorlin) 	Re: Comments about ROSIE/Tutorial/etc.
C00052 00006		Misc comments to Danny Gorlin
C00059 ENDMK
C⊗;
 8-Oct-80 11:35:19-PDT,763;000000000001
Mail-from: ARPANET site RAND-UNIX rcvd at 8-Oct-80 1135-PDT
Sender: Jeanne at Rand-Unix
Date:  8 Oct 1980 at 1134-PDT
To: CSD.GREINER at Score
From:     Jeanne @ RAND-UNIX
cc: Rick at Rand-Unix, Jeanne at Rand-Unix, CSD.LENAT at Su-Score
Subject:  ROSIE Tutorial


You will be most welcome at ROSIE tutorial.

Suggest you come down tonight (Wednesday) so that you can be here promptly
at 9am on Thursday for opening of session.

Take a taxi from airport when you arrive and allow plenty of time
whenever you arrive because there is danger of fog.

Call me at 393-0411, ext. 7349 or 7l53 or Rick Dow at 7681, if you need help
with reservations or anything else.  Rick will be available to escort
you from the guard station.


Jeanne Cartier
 8-Oct-80 15:50:56-PDT,602;000000000001
Mail-from: ARPANET site RAND-UNIX rcvd at 8-Oct-80 1550-PDT
From: Jeanne at Rand-Unix
Date:  8 Oct 1980 at 1550-PDT
To: CSD.GREINER at Su-Score
cc: Jeanne at Rand-Unix, Rick at Rand-Unix
Subject: Re:  ROSIE Tutorial
In-reply-to: Your message of 8 Oct 1980 1203-PDT.



Rick has asked me to advise you that these people will be attending from
outside Rand:

	Harold Cohen, consultant for Rand.  He is at Holiday Inn

	Bob Engelmore, DARPA Information Processing Techniques Office

	Mark Stefik, XEROX PARC - We're not sure yet when he arrives.



Have a good flight!



Jeanne
Mailed about noon, 21-October-80
TO: RICK@RAND-AI, GORLIN@RAND-AI
CC: CSD.LENAT@SCORE, CSD.GENESERETH@SCORE, STEFIK@PARC
SUBJECT: Comments about ROSIE/Tutorial/etc.

!	Presentation itself:

I thought the overall format was excellent -- the presentation, papers and
the like were uniformly good; and  all seemed at an appropriate level  and
pace.  I've only a few suggested additions:

1) I never  knew the precise  purpose of  this tutorial.  Was  it to  sell
ROSIE  or  critique  it;  or  perhaps   to  determine  the  best  way   of
demonstrating such systems in general, or presenting ROSIE in  particular?
Many of us attendees were pondering just why we were invited, and what was
expected of  us;  and a  concise  statement  of purpose  would  have  been
valuable.

Lacking any other direction, I tried to determine how ROSIE would fit into
my (and RLL's) future plans.  My  comments were attempts to figure how  to
get ROSIE to mesh with RLL, as  opposed to simply accepting the system  as
now stands.   These  suggestions  presuppose that  ROSIE  is  still  being
designed; I now realize such heckling may have been deliterious to you, if
this conference was designed simply to sell your system.

2) Like many  parts of the  system itself, a  statement of ROSIE's  design
philosophy was never explicitly presented.  I inferred the following:

"When released,  ROSIE  will  be a  static,  unalterable  language,  whose
interpreter is based on inflexible predefined semantics.  (I.e, it will be
more like  a  systems  language,  (such as  ADA)  than  an  extendable  AI
tools/environment,  e.g.    LISP.)    Its   two  major   goals   are   (1)
understandability and readility, together with (2) speed and efficiency --
in case of conflict  between these two attributes,  it is versatility  and
perspecuity which will be sacrificed.  (For example, no effort is made  to
facilitate further extensions to ROSIE, or to allow the user to mold ROSIE
to his specifications.)  ROSIE will house those non-controversal  features
which its  designers deem  necessary for  almost any  significant  system.
These will be  `opaguely' built into  the system; and  are NOT subject  to
modification -- at least not by the user."

The implicit assumption is that these  conventions will span the space  of
anything any  ROSIE user  will ever  wish  to do;  those with  a  slightly
different task are  better off NOT  using ROSIE.  The  user should  regard
ROSIE's language  as  unmodifiable;  he  is  not  allowed  to  modify  its
interpreter, and neither he nor ROSIE is permitted to reorganize (or  even
reason about) the internal data structures.

3) It was never clear just what  ROSIE's real mission in life was --  just
whom was it designed to serve, and  for what task.  As it was  represented
at the  ES  Workshop  I assumed  it  could  be used  for  designing  large
programs.  But then it seemed  strange (i.e.  contrary to its  philosophy;
see 2) above) that  ROSIE did not have  built-in parts designed to  reason
about standard  programming constructs,  such as  sequence of  operations.
[ROSIE doesn't "know" about  sequences the way it  knows about classes  --
i.e. it includes determiners,  which are only  applicable to classes;  but
not a  pre-defined  semantic interpretation  for  things like  BEFORE  and
AFTER?]

Was ROSIE designed  to handle  general applications?  If so,  how can  the
claim that "then ROSIE probably isn't  what you should be using" serve  as
an acceptable justification, to explain away some limitation?

I would be nice to see explicitly what assumptions and conscious decisions
went into  ROSIE's  design.  For  example,  how  large do  you  image  the
eventual  user's  Knowledge  Bases  will   be?   Will  it  only  be   used
interactively? ...

4) The final suggestion  is to include a  projected life story for  ROSIE:
Do you  imagine ROSIE  will undergo  a KRL-like  sequence of  generations?
Will the user be allowed to modify its internals, ever?  Is RAND committed
to support ROSIE indefinitely? etc.

!	General comments

I was quite (positively)  impressed with what ROSIE  could do -- it  could
certainly handle 95% of all the tasks I could ever imagine, and do so in a
fairly clean  and elegant  manner.   What has  me  frustrated is  not  the
particulars of  those remaining  5% of  the  facts --  after all,  no  one
expects any  system to  please all  the users  all the  time.  Rather,  my
concern was due to  the fact that so  many arbitrary decisions were  built
into ROSIE, and  encoded in such  a way  (and in such  a philosophy)  that
every user will be forced to mold his data to fit these conventions.

The approach sounds similar to Yale's:  All we need to do is build in  the
5 basic this-es and 6 primitive that-s.  As no one will ever need anything
else, the system will never need to change.  So why bother installing  the
tools which faciliates (or even simply allow) the system to be modified?

Representation languages are based  on the premise  that this user  should
decide what consistutes a natural decomposition of the problem.  They  are
necessary because such systems soon become  so big and intricate the  user
is unable to cope with  its complexities effectively.  Such languages  can
be viewed as general  tools, designed to assist  the user in building  and
later modifying a large system.

From this perspective  it is hard  to understand the  assumption that  the
user will  happily  accept someone  else's  conception of  how  he  should
process his data,  or how he  should go about  drawing inferences.   Given
that ROSIE was  designed to accept  as input arbitrary  "domain" facts  --
about people, hats, or frogs; together with their properties -- why has so
little been done  to permit the  user to  specify how to  deal with  these
facts --  how to  perform inferences,  retrieve stored  values or  propage
effects.  How  can ROSIE  simultaneously  assume that  (1) there  is  much
declarative information which is particular to this problem, which should,
as such, be input by the user, and (2) there is nothing the user needs  to
say about  how to  process  this information  --  i.e.  a  single  general
processor is sufficient to deal with  this, as well as ANY OTHER  PROBLEM;
and so there is no  need for the user to  enter this type of  information.
ROSIE is, of course,  not alone in making  this artificial distinction  --
there has been a  historical dichotomy between  enterable data and  static
program.  That doesn't mean this approach  is any more justified, or  less
limited.

This problem  can  be readily  solved  by a  single  obvious-in-retrospect
"trick":   Simply  leave  all  of  the  control  mechanisms  visible   and
modifiable.  This would be achieved elegantly if all of the internal parts
were encoded in forms ROSIE itself can understand (e.g. as ROSIE  stylized
English).  It is, however, quite sufficient  to leave these as LISP  code;
the only necessary requirement is that they be reachable.

Ideally ROSIE's  guts should  be self-descriptive  and modifiable.   Given
that ROSIE was designed to help construct other programs, it seems strange
to find it unable to turn inward and aid in its own modifications.   After
all, this particular system  is just the sort  of complex beast ROSIE  was
designed to construct and  manipulate.  It's as if  these builders do  not
believe in  the very  raison  d'etre for  their  own system.   ([RLL-1:  A
Rep...] illustrates why, with proper bootstrapping, this need NOT lead  to
an infinite descent.)

The  argument  that  such   flexibility  causes  inefficiency  is   simply
fallacious.  Yes, it will cost considerable additional space, but  already
much of ROSIE's design  seems strongly based on  the assumption that  vast
quantities of storage  are just  around the corner  -- to  house both  the
system itself  and the  user's data.   Employing Cognitive  Economy  ideas
(e.g. retaining multiple version  of various parts  of the program)  we've
seen such language can  reclaim otherwise lost  execution speed; so  speed
need not be sacraficed either.

The next standard concern is  that this way the  user has too much  power,
and can all  too easily screw  himself.  There are  two arguments  against
this:  (1) We recommend that ROSIE  provide nice safe tools -- which  know
about what the user should and  should not be tampering with.  Of  course,
the sophisticated (and maschocistic) fellow can still ignore these  access
mechanisms, but (2) there is no way we can really provide a totally  idiot
proof system.  No  matter how many  precautions we include,  the user  can
always type ↑C, or do funny things with random parts of memory.  The  only
guarantee we'll make is that the user  will be safe if he plays only  with
the toys we  provide.  [Note these  enclosed tools are  part of the  ROSIE
system, and should, as such, also be alterable.]

Enough philosophy.  Many of these points,  at some level or other, can  be
found  in   "A   Representation   Language   Language"   [AAAI#1   165-9],
"Meta-Description and Modifiability" [Genesereth&Lenat, HPP 80-18] "RLL-1:
A  Representation  Language  Language"  [HPP-80-9],  "MRS  Manual"   [Mike
Genesereth & Dave  Smith, HPP-80-24], description  of Cordell Green's  Chi
project (especially Jorge Phillip's PhD thesis) and (sorta) in Jon Doyle's
PhD thesis (c.f. p. 35 on).

!	Specific limitations

This list which follows should NOT be interpreted as  a want-list;
 I do NOT want one  of
ROSIE's builders to sit down  and integrate solutions to these  particular
problems into ROSIE's code.  Nor  am I particularly interested in  finding
some thirty line ROSIE progam which sorta simulates some fact which I  can
state in one sentence; and would be even more disappointed to find I would
have to  keep asserting  additional facts,  one for  each new  proposition
enterred, for my requested rule to continue to hold.  (Of course,
finding that such a
possibility does exist would  constitute a step in the  right
direction.)  Both of these approaches represent what I feel to be a  major
loss in perspecuity -- which I thought  to be one of ROSIE's main  selling
points.

Unfortunately these examples  reflect  my  rather incomplete
understanding of the ROSIE system, which does not necessarily do
justice to the actual ROSIE system.
I would be pleased to discover that ROSIE could indeed perform some task I
here claim was beyond its capabilites.
Please realize the purpose of this list is 
not to badmouth ROSIE, per se; rather it was designed 
to demonstrate the
limitations which arise whenever the user is supplied with
a single unalterable interpreter.

The categories used below  are merely first stabs  at an ordering of  the
ROSIE's limitations. Many of these examples overlap into other divisions as well.

!O. Lack of intensional objects.
This has already been acknowledged as a shortcoming;
I am including it in my list only for completion.
This omission leads to other problems - such as the inability to
deal with skolemized variables (eg Mark's
	Any man with a hat ...
where the particular hat is a function of the particular man.)

I. The Backward Deduction Inferencing Capability is fixed, and unalterable.
All it can do, apparently, is specify
	For-All x in C. Q(x) & M P(x) => P(x)
where "M P(x)" is a modal statement that asserts P(x) is not inconsistent.

Limitations:

1) Can one refer to existential quantification?
[Note this could be handled using intensional objects; but lacking those,
this omission is even more glaring.]
How can I assert that
	"There is a green frog."
in such a way that asking
	"Are all frogs red?"
is guaranteed to be False.
Note ROSIE's current trick, of simply skolemizing this frog into a constant,
is NOT sufficient.
[Scenario: 
	Assert any thing red is not green.
	Assert there is a green frog.
	?
	   Frog#32
		Frog#32 is a FROG.
		Frog#32 is green.
	Assert Frog#32 is red.
	Display Are all frogs red?
		True.
]

2) Why must each description have a scoping class?
This forces the user to talk about "things", to sidestep this limitation.
However, this happens in English as well, so this point is not major.

3) Modalities
How can I state that
	"Any proposition not provably true is false."
Reason Maintenance
	"The proposition X is only true when proposition Y is true."
	"The proposition X depends on Modus Ponens."
Resource limitations:
	"Spend up to 10 cpu second trying to deduce proposition X."
	"Do not spend over 10 cpu second trying to deduce any proposition."

This is crucial for work with beliefs and alternate worlds, where I might
want to assert something about John's deductive mechanism (i.e. that he
does NOT know Modus Tollens).

4) Disjunctions:
From
	Assert Tom is either green or blue.
	Assert Tom is not blue.
could ROSIE infer that
	Tom is green.
?
Similarly could ROSIE do the right thing with
	Assert any man is either green or blue.
?

5) Arbitrary complexities:
E.g. It should be easy to "enhance" the inference engine to work slightly
differently.
In one statement I should be able to say
	Combining "Any <descr1> is a <descr2> with (any probability (p))."
	with "Any <descr2> is a <descr3> with (any probability (q))."
	yields "Any <descr1> is a <descr3> with r." where r = p*q.
Perhaps an even more general statement, describing how to combine probabilities,
should be expressible.

II. Why is the interpretation of each phrase so rigidly predefined?
This seems quite a loss, especially considering its arbitrariness.
For example, why do you insist that every fake diamond be an diamond?
This would be acceptable if there was an easy way to override it -- for example,
a statement that
	"Any thing which is a fake -class- is not a -class-."
where -class- varies over every class. (See III.1). )
Analogous, it is a shame the user cannot state that
	"Any thing which is a -class- in -anything- is a -class-.",
etc.
[This would be used to deduce that 
	TheAmazon is a river.
given the assertion that
	Assert TheAmazon is a river in Africa.
]

ROSIE "knows" a lot about classes,  and handles them fairly nicely.   This
is NOT true of sequences, which can, at best, be expressed only as  lists.
Why not give some semantics to "BEFORE", or "CONCURRENTLY", by analogy  to
THE or A.

Providing the user with this ability to change the ROSIE system would be a
giant step  forward,  even if  the  user  had to  issue  these  redefining
instructions in  LISP.  It  would be  much better  yet if  the user  could
simply issue such ROSIE-altering commands to ROSIE in the ROSIE language.

III. Many facts only stored implicitly.
For example, it is  difficult to refer  to individual classes,  relations,
prepositions or propositions;  and harder  to quantify over  any of  these
sets.

1) Classes
[Note many of the problems mentioned throughout would be solved if we 
could place an arbitrary class in a user function or procedure.]

Is there any way to refer to a particular class, as an entity with properties?
For example, can I say
	Assert the number of frog is 5.
and
	Assert the latest-addition to frog is Frogette.
where this "frog" is the same object I use when I state that
	Assert Frogette is a frog.

If so, can I set the demon
	"When any '-Y- is a -X-' is asserted,
		LET the size of -X- be 1 + the size of -X-."

It appears this would really require an infinite number of
assertion to put into effect  (ie one for each possible class -Y-).
[This might get even more complicated if -X- could vary over every 
description -- this would require that ROSIE have to have a unit 
which represents, for example, the set of "lakes in Africa".]

2) Prepositions
How could the user define new ones, or assert some property of an existing one --
eg that the "value" of "with" must be a probability,
or which lists those functions which use "of" in their invocation pattern.

3) Propositions
Quantification:
	Describe all unary propositions involving Fred.
	Describe all positive propositions involving Fred.
		[similarly CURRENT tense, or PAST TENSE;
		 or relations which start with Is-A, ...]
Inheritance:
	Any man should `inherit' all the relations stored on TypicalMan.
		[That is, after asserting that John is a man,
		 John should inherit a copy of each proposition stored on
		 TypicalMan, mutatis mutandis.]
[It would be even better if the user had first indicated which
 properties/relations were inheritable, and which pertained to this entity
 alone. Then John would receive only the semantic attributes of TypicalMan,
 not the syntactic properties of this unit.]

Epistemological Marks:
There are many facts - such as marks which indicate epistemological status
- which should  be associated with  the actual proposition.   Eg The  fact
that "Every  purple  mushroom is  purple."  is definitional,  whereas  the
statement  that  "Each  purple  mushroom  is  poisonous."   is  simply  an
assertion, which just happens to be true.

Much of what "ANY" does would be clarified with such marks as well:
Given
	Assert Fred is an albino frog.
	Assert Any frog's color is green.
	Assert The color of any thing which is albino is white.
The result of
	DISPLAY The color of Fred.
is ill-defined.  - i.e. it might be either "Green" or "White".
It would be nice to be able to state
	Assert the proposition that 
		'Any frog's color is green'
		is assertional to frog.
	Assert the proposition that 
		'the color of any thing which is albino is white'
		is definitional to albino.
	Assert ... ANY should look first at Definitional properties before
		Assertional ones ...
[Note the final assertion requires a handle into the inference procedure 
associated with ANY -- see I. above]
In this case, the answer would clearly by "White", as desired.

If and when intentional objects are implemented,
they could make heavy use of such marks.
They should be used to differentiate between
	The green man hit the baseball,
which is defined as a man who is green, and happened to hit the baseball, from
	The man who hit the baseball is green,
which is defined as a man who hit the baseball and happens to be green.
This distinction is essential for matching purposes.

4) Relations
	Describe all proposition containing the Is-A relation, which involve Fred.
		[This would list every class to which Fred belonged, eg:]
	   Fred is a boy.
	   Fred is a man at [age] 12.
	   Fred is a sailor on HMS-Pinafore.
How about a user defined relation:
	The "is-tall" relation is nice.
	The "Isa-Of-With" relation is significant.
	Any significant relation is nice.
then
	Describe all proposition based on a nice relation, which involve Fred.
[It would be even nicer if the user could instruct the parser to accept phrases
like
	Describe all nice relations in which Fred participates.
which would mean the same as the above statement.]

On a similar vein, if one could readily quantify over relations, the basic frame
statement would be a cinch:
	Assert for every asserted proposition which involved a WAS relation,
		the corresponding proposition, with the WAS replaced with an Is,
		is provably true.

[Side question: Is the "asserted proposition" construct permissible,
meaning, of couse, "a proposition which was asserted"?]

Can I relate each n-ary relation with a corresponding n+1-ary relation,
whose final arg relates to time -- ie first consider
	Assert for every instantiation of Isa, (Isa x class),
		the proposition (Isa' x class t0) is provably true.
then extend this by quantifying over all relations.
Similarly one might want to conjoin an epistemological mark on each proposition,
using this type of trick.

There are many properties associated with properties as well.
For example
	Assert income is singlevalued.
would cause an error if 
	Assert the income of Fred is 45.
followed
	Assert the income of Fred is 100.
[Another possibility:  this might have the effect of simply erasing the
earlier (Income John 45) proposition.
The choice of which of these to use should depend, of course, on the
current user's whims.]
Note this is not always the case - eg we can have
	Assert the son of Fred is John.
	Assert the son of Fred is Mark.
(In fact, it should be an error using "the" above - as the property was not
singlevalued.)

[Another improvement to the parser:
How about giving "sonS" the obvious interpretation?
So 
	Assert the sons of Fred are John and Mark.
would accomplish the same as the above two sentences.]

Finally,  can  ROSIE  reason  (or  assert  facts)  about  Demons,  or  Any
statements, qua facts?  For example, how can one phrase the instruction to
delete a When demon after its one execution, or to eliminate any Any demon
which has not fired today, or ...

IV. The parser is, to the user, totally inflexible.
This linguistic issue is not a major shortcoming. Still,

1) it would be nice if ROSIE  could adapt to the user.  For example,  some
user could instruct  ROSIE that he  (intentially or otherwise)  constantly
mispelled some keyword, or  misordered some phrase --  this would allow  a
preparser to replace this "error" with what the user really meant.

2) How  about  allowing  the user  to  define  a SUBSET  of  the  grammar.
(Clearly this will  not be  ambiguous if the  full grammar  is not.)   For
example, for type checking reasons, the  user may want to insist that  the
"value" associated with the preposition "with" be a probability.  That way
"roof with 0.7" would be acceptable, whereas "roof with spikes" would blow
up immediately.  (Of  course, better  yet would  be allowing  the user  to
define a new "with-probability" preposition, with this typing.)

3) The invocation pattern of a function is fairly constrained.  Enlargening
this, to include, for example, adjectives before the noun, might prove a big
win.

V. Grab bag

1) Can the user create his own monitor, or submonitor? Ideally, he  should
be able  to construct  his by  slightly modifying  an existing  one.   For
example, could the user  define a monitor which  chooses a rule at  random
and executes it.  Unless that rule  RETURNed or QUIT,  this monitor  would
then execute  another rule,  and so  on.  Are  there sub  monitors? (Ie  a
partition of the ruleset into sub groups of rules, where each such  subset
has its own monitor.)

2) I got the impression that only primitive sentence could be propositions.
If true, that's a considerable limitation.

3) Is it possible to reason about some user or system function -- that is,
store axioms which it satisfies, and  use these facts.  Better, could  one
make some change to these assertions, and see the function itself  altered
correspondingly.  (Similarly for Predicates and Procedures.)

4) Cognitive Economy - can the same  name be used for a ROSIE relation  as
for a user function.  Then  when the (Father of  X) inquire was made,  the
Father function could first see if the triple (Father X Y) appears in  the
KB; and if not does some other calculations.  The result of this execution
may then be cached away (so subsequent calls would be faster.)

5) Does ROSIE have different input modes
-- for example, a useful one would be a paraphrasing mode,
in which ROSIE returns what it thought the user had said.

6) Can the user input, and ROSIE use, MetaRules?  This would be a nice way
for the user  to help ROSIE  perform a derivation.   For example, can  the
user order the rules ROSIE uses, or  tell ROSIE how to quickly prune  away
irrelevant ones? (This  had been a  problem with PROLOG,  and before  that
with PLANNER.  An article in IJCAI#6 presents arguments for the utility of
this idea.)

!	Path towards a solution:

There are many  ways to solve  these particular shortcomings.   One is  to
make them features:  "ROSIE intentionally  handles a fixed predefined  and
stylized subset of English, to avoid ambiguities, and for parsing  speed."
Another is to  address the  precise complaint,  and add  in code  designed
explicitly to  fix  this "bug".  These  are  NOT the  approaches  I  would
advocate.  After  all, these  particular issues  only reflect  my  biases,
which should have no more weight than any one else's -- in fact, less,  as
I'll not  be using  ROSIE in  the immediate  future.  This  collection  of
troublesome facts was intended to  demonstrate the major problem  inherent
to any closed  system:  that  any outsider can  easily produce  a host  of
problems, which  either cannot  be  handled, or  which cannot  be  handled
easily.

This problem goes away if the guts  of your system is left exposed to  the
user; and if he is provided with a library of effective tools for altering
the parts of this interpreter in whatever manner he wishes.  The  designer
is still expected to build into ROSIE the things which seem expedient  for
95% of the cases, but now the user  is NOT forced to use these when  these
conventions prove inadequate or inappropriate.

This way there is no need to either apologize for ROSIE's ineptitudes,  or
hastily get a system programmer to patch  up a solution -- after all,  the
user now has  last word in  what ROSIE can  and will do,  and with it  the
responsibilities for any  shortcomings in  his design.  At  this point  he
becomes responsible not only for modifying his system, but for maintaining
it as well.  Note  these tools are not  that expensive to construct;  they
may be essentially  the same ones  you, the system  builder, use for  your
manipulations.  The time required  now to build these  tools for user  use
will be repaid many times  over by the time you'll  save by NOT having  to
modify ROSIE, as the user himself can have his whim.  The other cost -  of
making the system itself  understandable - hardly seems  a goal to  avoid.
Among other desirable effects, this makes much of the system far easier to
actually build.

Based on my experience working with  RLL-1, I strongly believe I  actually
spent LESS time and effort building a self-modifiable system than I'd have
spent constructing a more opague system.  That is, it was easy to  upgrade
RLL-1 using these modifying tools --  it was, in fact, trivial to  perform
simple alterations.  There were  big gains from a  more esoteric point  of
view as well -- I was amazed at how many issues became now non-issues when
the interpreter itself was explicit.  (Eg  just what does the "Any"  demon
REALLY mean?)
∂22-Oct-80  2038	RICK at RAND-AI 	Re: Comments about ROSIE/Tutorial/etc.
Date: 22 Oct 1980 1818-PDT
From: RICK at RAND-AI
Subject: Re: Comments about ROSIE/Tutorial/etc.
To: RDG at SU-AI, gorlin at RAND-AI
cc: csd.lenat at SU-SCORE, csd.genesereth at SU-SCORE, stefik at PARC-MAXC
In-Reply-To: Your message of 21-Oct-80 1256-PDT

Russ:
	I am grateful for the careful and persuasive remarks you 
prepared on ROSIE.  More than any thing, they heighten and articulate
the tensions associated with a project like ROSIE:  exactly what is
the purpose and who is the user community.  Inviting you has been
repaid.  The answer to most of your questions is that they provide
capabilities not required by the intended audience for ROSIE, who are
pretty much unskilled-in-AI knowledge programmers.  I don't think
that ROSIE Makes all of their task easier than it would be if we
had all the capabilities you  suggest.  For example, I personally
prefer many of the more powerful capabilities you recommend since
they make lots of things easier.  On the other hand, it's not
immediately obvious how to gracefully extend the system.  It's a
large (ADA=like) programming system, and unfortunately many features
interact with others.  That's not copping out, that's admitting that
you've given us several more things to chew on.  As that process
unfolds, I'll consult with you to see if we can't get some of these
capabilities realized.  I warn you, however, there are more
constraints than immediately obvious.  For example, all propositions
are primitive sentences because that's what's in the data base and
that makes matching well-defined, simple, fast and compilable.
We don't carry around arbitary variabilized expressions for later
evaluation.  Why not?  Because we want something that can compile, be
simple, and be fast.  Maybe we're sacrificing too much for something
of too little value, but those are the really interesting and hard
issues.

      I have read your note once carefully, and it's apparent to
me that your ideas are worth more than that.  I will return!

	Again, thanks,

			Rick


p.s.  our intention was to inform potential users and instigate
useful reactions.  i think we got that from you.

-------

∂22-Oct-80  2037	GORLIN at RAND-AI (Dan Gorlin) 	Re: Comments about ROSIE/Tutorial/etc.
To: RDG at SU-AI, rick at RAND-AI
cc: csd.lenat at SU-SCORE, csd.genesereth at SU-SCORE, stefik at PARC-MAXC,
cc: GORLIN at RAND-AI
In-Reply-To: Your message of 21-Oct-80 1256-PDT


Russ,

Ditto on rick's comments. Your critique is by far the most comprehensive
and cogent we've received, and will undoubtedly affect Rosie's future
in a big way. Much more to say, but I'd rather do it over the phone
after having contemplated the issues. Thanks for the help.

danny

-------

	Misc comments to Danny Gorlin
15-Nov-80 11:38:49-PST,681;000000000001
Date: 15 Nov 1980 1138-PST
From: GREINER
Subject: Small Lisp
To: gorlIN
cc: GREINER

Do you still need the "SMALLISP" and MAKESMALLISP files on my account?
(Recall these were snarfed from SCORE; written initially by DEA.)
	Also, could you mention, briefly, what the long-term status of ROSIE
is?  Do you plan to have release successive versions of the system? If so,
have you drawn up a timetable?  Will each user group be supplied with a 
"Want-List" type of questionaire?  Will you personally, remain, (for a
non-trivial while,) the official ROSIE designer/hacker/implementor; 
or will there eventually be several serving that function(s)?
	Thanks,
Russ
-------
17-Nov-80 08:11:16-PST,960;000000000001
Date: 17 Nov 1980 0811-PST
From: GORLIN (Dan Gorlin)
Subject: Re: Small Lisp
To: GREINER
cc: GORLIN
In-Reply-To: Your message of 15-Nov-80 1138-PST


Hi Russ,

No I don't need the SMALLISP stuff. Doug has since fixed some bugs in it,
so your copies are outdated in case you need to know.

In some ways, Rosie is still being designed. I'm currently the only
implementer/designer, and that won't change until the first real release
of a complete Rosie (Jan or Feb). At that time, Henry Sowizral will 
probably take over and begin to install Rosie at other sites.

I'll be avoiding the priority/want-list trap as much as possible, since
I really haven't the manpower to handle it. I think we'll just avoid
distributing outside of Rand until we're confident of the product.
Another iteration of Rosie (in response to wide usage) won't happen for
at least another 6 months. 

What's your concern? You waiting to use it?


danny
-------
17-Nov-80 11:32:14-PST,594;000000000001
Date: 17 Nov 1980 1132-PST
From: GREINER
Subject: Re: Small Lisp
To: GORLIN
cc: GREINER
In-Reply-To: Your message of 17-Nov-80 0811-PST

My "concern" s basically curiousity.  In particular, I wanted to know
whether you envisioned a community of Rosie users growing up; and if so,
how you planned to respond to their needs. (This is because both RLL-1 and
MRS will soon be in such a state, and I wanted a model to see how others
handled such situations.)

Do you know the full story about the ESWS shirts?
(Will they have Duda's picture, or was that sacrificed?)

Russ
-------
17-Nov-80 11:58:58-PST,1446;000000000001
Date: 17 Nov 1980 1158-PST
From: GORLIN (Dan Gorlin)
Subject: Re: Small Lisp
To: GREINER
cc: GORLIN

I've had nothing to do with the T-shirts, and have no info on them.

As for Rosie maturing, my gut feeling is that there is now and will
always be no doubt in our minds as to what needs changing in Rosie.
Even now with about 3 users, I've had plenty of complaints/requests,
and your note should keep me busy for some time. 

We plan to support users in a few ways. 
1). Help. Three or four Rosie "experts" will be available to
answer questions.
2). Examples. One of our documents is strictly examples, as you know.
3). System Rulesets. Rosie will be expanding to user needs via
the System Ruleset mechanism. Libraries of these rulesets will be
developed, analagous to a <LISPUSERS> directory. I suspect this
tack will satisfy 80 % of user obstacles (probably 50 % gracefully).

Probably the hardest part will be filtering user complaints/suggestions
for relevance. You experienced some of our "then they shouldn't use
Rosie" rationalization, so you know how we'll try to approach this.
The hard part will be keeping an open mind and not discarding useful
information. Unfortunately, we'll be more or less frozen after a large 
distribution, and for this reason I'm delaying that event as long as 
Rick will tolerate it.

I imagine your problems with RLL users will be similar to ours. Good luck!

danny
-------
-------